Closes #3357

Problem

pandas 3.0 defaults timestamps to datetime64[us] resolution. When writing
parquet files containing timestamps outside the nanosecond range (before 1677
or after 2262), data was silently corrupted on read-back.

Root cause: the write defaults flavor="spark" and version="1.0" in
s3/_write_parquet.py force all timestamps to INT96 physical storage
(nanosecond-only). Coercing datetime64[us] values outside the nanosecond
range into INT96 overflows, producing garbage timestamps on read.

Changes

awswrangler/s3/_write_parquet.py

• coerce_timestamps: "ms" → "us" — prevents microsecond precision loss
• flavor: "spark" → None — removes forced INT96 physical storage
• version: "1.0" → "2.6" — uses typed timestamps instead of INT96

awswrangler/_data_types.py

• pyarrow2pandas_defaults: add coerce_temporal_nanoseconds=False — prevents
  pyarrow from casting timestamp[us] back to datetime64[ns] on read
• athena2pyarrow: map all pandas datetime resolutions (ns/us/ms/s) to the
  correct pyarrow timestamp unit; default to us for pandas 3.0+
• Fix pre-existing bug: dtype in ("binary" or "varbinary") →
  dtype in ("binary", "varbinary") — "binary" or "varbinary" evaluated
  to "binary" only, causing varbinary to raise UnsupportedType

Verification

import pandas as pd
import awswrangler as wr

df = pd.DataFrame({
    "ts": pd.to_datetime([
        "1000-01-01 12:00:00",  # outside ns range
        "1677-10-01 12:00:00",  # inside ns range
        "3000-01-01 12:00:00",  # outside ns range
    ])
})
# Before: read-back returned corrupted timestamps for rows 0 and 2
# After:  all rows round-trip correctly as datetime64[us]